get this from a dts

This is a software timer and there is no crystal running at this frequency that's why it is set in Kconfig. What do you think now?

hardware timer with software configurability? That can be represented in dts, it's going through a hardware block

Let me explain more:
SYS_CLOCK_HW_CYCLES_PER_SEC=409600 is the system time unit (STU). One STU is equal to 625/256 μs (about 2.4414 μs). It is independent to the hardware oscillator variation. Every timeout event is expressed in STU. Only before programming the real counter, the time expressed in STU is converted to the hardware timer counting unit internally from the radio timer driver.
Do you still think that it should be defined in a DTS file?

so then the radio timer driver is wrong? This value should be the hardware cycles per second, as the name implies, there shouldn't be some software translation in a radio driver that changes this into the actual value that the hardware uses, it should be using the hardware value directly

If we use the LSE (low-speed external 32.768 kHz), the SYS_CLOCK_HW_CYCLES_PER_SEC can be calculated and is well known. However, when using the LSI (low-speed internal), this value varies because the clock frequency is unknown and differs between devices within a certain range. In our Bluetooth protocol implementation, it is easier to use the STU, which is fixed and independent of both LSI and LSE. We manage internally this value according to the different HW configuration.

sure, but the value is known, it can be assigned to a node in dts then retrieved, it is hardware

Done.

the NULL check should be 1st, and it should result in a panic or reset or something if it's not excepted.

I don't understand the purpose of "the NULL check should be 1st," Can you explain more?
For the second part, you mean to put something like __ASSERT_NO_MSG(buf);?

What I meant is

	if (buf == NULL) {
                LOG_ERR("Buf is null");
                Panic/return error if pointer should never be Null
        }
	/* Handle the received HCI data */
	LOG_DBG("New event %p len %u type %u", buf, buf->len, buf->data[0]);
	hci->recv(dev, buf);

At the moment, the null check is implemented in the else. Since the function is void, it's not returning any error, and also the situation is not critical to panic. So, LOG_ERR is enough.

the null check is implemented in the else

That's not a good coding pattern in my opinion.

There should be a way to use fts and gpio hog to do this.

AFAIK, gpio hog is used to automatically set a GPIO pin at boot, but in this file these pull-up/pull-down configs are related to PWR register and they will be applied when the SoC enters suspend-to-ram state. In other words, they are not used in active state.

Actually, we do keep PWRC_CR1.APC at default value and configure GPIO pull-up/pull-down via PWR on WB0 series:

so this configuration would be applied all the time, as far as I understand. (and most importantly: lost if the application changes the pins' configuration!)

You're right. So, I should implement these pull-up/pull-down configs in the board's DTS file?

Yes. You should use a GPIO hog as suggested by @erwango.
See example here:

As far as I noticed, it sets the pin state at boot time, and it's not related to pull-up/pull-down configs. It doesn't support bias-pull-up and bias-pull-down properties.

Have you tried using gpios = <xx GPIO_PULL_UP> / gpios = <xx GPIO_PULL_DOWN>? From my understanding of the hog driver, it should work.

Done.

Use of imply make it possible that activation if not done if dependency is not met, w/o any error reported.
When using select an error will be generated if dependencies of selected symbol is not met and hence expected configuration cannot be met.
Is that done on purpose ?

Do you mean why select ... if ... is not used instead?

I think using select ... if PM for all should work.
I may have used imply to avoid repeating the if PM.

Done.

I think we should be able to put that definition in a header somewhere - or in fact, it may already be! - instead of re-defining it in every driver.

What do you think about defining it in include/zephyr/dt-bindings/clock/stm32_common_clocks.h

This header is for DT bindings only, it should just contain (un)packing macros for DT->driver exchanges.

I think placing the definition in <soc.h> (soc/st/stm32/stm32wb0x/soc.h) would be acceptable. The header might also be already by drivers too.

In this case, it's only for WB0x. What about other STM32 products?

Maybe it could go in here? I was suggesting <soc.h> because I was a bit worried WB0 that including this file on WB0 would blow up, but now I realize it's actually used and my fears are unjustified 😅

Name should be changed if we place it in the general file, maybe to something like STM32_MAIN_SYSTEM_FREQ (because it corresponds to AXI frequency on some SoCs).

Note that the definition will be unused on all other STM32 until we clean-up the SYS_CLOCK_HW_CYCLES_PER_SEC mess, which will be done in another PR, hence why having something WB0-specific for now is fine (IMO)

Ok. I implemented in soc/st/stm32/stm32wb0x/soc.h

It seems that soc.h wasn't a good idea since rtc_ll_stm32.c and entropy_stm32.c are not WB0-only drivers. So, I'll define it in stm32_clock_control.h as you suggested above.

Move this to the HCI_DEVICE_INIT() macro:

+

#define HCI_DEVICE_INIT(inst) \
+       PM_DEVICE_DT_INST_DEFINE(inst, ble_pm_action);
	static struct hci_data hci_data_##inst = { \
	}; \

Done.

Done.

Nit:

+ we should check if the slow-clock property on rcc is clk_lsi instead... but that's fine.

Done.

I think using select ... if PM for all should work.
I may have used imply to avoid repeating the if PM.

I think putting these directives in a if STM32_RADIO_TIMER block would yield the same result.

Done.

Nit:

Done.

Done.

Can remove the outer parentheses in the 3 lines above.

Done.

You can drop these 2 lines, for consistency in the Zephyr source tree.